Add PlainTextRange interface #1404

stephanieyzhang · 2025-09-12T13:58:15Z

PlainTextRange is a specialized, live AbstractRange subclass for the value space of <input>/<textarea> and other elements whose specifications define that they support plain text ranges. It enables range-based operations in the element's logical value while restricting standard Range mutations to preserve encapsulation. It integrates cleanly with existing selection/editing behavior and closes a long-standing gap.

Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/FormControlRange/explainer.md
WHATWG Discussion: FormControlRange Interface html#11478
Corresponding HTML Spec PR: Integrate PlainTextRange hooks into text controls (input/textarea) html#11741
Corresponding CSSOM PR: [cssom-view-1] Add PlainTextRange geometry APIs (getClientRects/getBoundingClientRects) w3c/csswg-drafts#12904
At least two implementers are interested (and none opposed):
- Microsoft Edge
- WebKit: FormControlRange - Live ranges for <input> and <textarea> WebKit/standards-positions#541
- Mozilla: FormControlRange - Live ranges for <input> and <textarea> mozilla/standards-positions#1289
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/dom/ranges/tentative?label=master&label=experimental&aligned
- PR to make tests non-tentative: Make PlainTextRanges tests non-tentative web-platform-tests/wpt#55014
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/421421332
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990256
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=299375
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

Preview | Diff

dandclark

Great to see a spec for this coming together!

dom.bs

rniwa · 2025-09-29T17:13:08Z

FWIW, I'd rather extend Range so that it can work with shadow host in general instead of creating a new interface specifically for form controls.

stephanieyzhang · 2025-09-30T20:10:42Z

FWIW, I'd rather extend Range so that it can work with shadow host in general instead of creating a new interface specifically for form controls.

We explored extending Range, including shadow host support, but found compatibility and encapsulation issues that made it risky to change existing Range semantics. Based on feedback across discussions, we went with a dedicated FormControlRange instead. The trade-offs and alternatives are covered in the explainer.

rniwa · 2025-09-30T20:43:22Z

FWIW, I'd rather extend Range so that it can work with shadow host in general instead of creating a new interface specifically for form controls.

We explored extending Range, including shadow host support, but found compatibility and encapsulation issues that made it risky to change existing Range semantics. Based on feedback across discussions, we went with a dedicated FormControlRange instead. The trade-offs and alternatives are covered in the explainer.

Changing the behavior of setStart/setEnd wouldn't be an only way to solve this problem. I'd instead add a new argument or a new function which specifies "offset" within element's shadow tree.

dandclark

This is looking good! Next big steps will be defining the right integration points from the HTML spec, and working towards consensus on the API shape.

dom.bs

dandclark · 2025-09-30T21:37:56Z

dom.bs

+ <a>this</a>'s <a for=FormControlRange>end offset</a> to <var>endOffset</var>.
+</ol>
+
+<p>If an {{HTMLInputElement}}'s <code>type</code> changes to a type that does not


(this, too, will likely need to be something that we'll need to put in the HTML spec)

dom.bs

dandclark · 2025-09-30T22:09:46Z

Changing the behavior of setStart/setEnd wouldn't be an only way to solve this problem. I'd instead add a new argument or a new function which specifies "offset" within element's shadow tree.

@rniwa Thanks for the feedback! Yeah, there are a lot of ways this could be done. This suggestion sounds closer to the 2nd considered approach here. There are enough differences in how a Range inside a builtin element would work vs a "normal" range that we believe it will be overall cleaner and less confusing to split the functionality into a different type. For example the behavior we propose here is that a FormControlRange can't have one boundary point inside a <textarea>/<input> and another boundary point outside, which would be a clumsier invariant to express with the Range API surface. Adding this to Range would also add confusion about what things like Range.selectNodeContents should do; should it move the range to select an <input>'s value string, or not? We could add a parameter to all the setter functions to switch the behavior, but again it seems cleaner to relegate the behavior to a different interface vs adding parameters to a bunch of Range functions.

Anyway, whatwg/html#11478 is a better place to have this discussion -- more folks are following that issue vs this draft PR. @stephanieyzhang it might be helpful if you could update the PR description for this to point to that issue, as well as a direct link to the explainer.

annevk · 2025-12-08T07:09:40Z

dom.bs

+
+<pre class=idl>
+[Exposed=Window]
+interface PlainTextRange : AbstractRange {


I think this is the wrong name now the idea is to no longer tie it to text.

annevk · 2025-12-08T07:12:00Z

dom.bs

+
+<ul>
+ <li><p><dfn export for=PlainTextRange id=plaintext-range-host>host</dfn> (null or an
+ {{Element}}).</p></li>


Why do we need this? The host should be in charge of allocating these at which point these don't really need to have a host owner.

annevk · 2025-12-08T07:13:27Z

dom.bs

+</ul>
+
+<p>The {{AbstractRange/startContainer}} getter steps for {{PlainTextRange}} objects are to return
+null.</p>


This doesn't work. You need to adjust AbstractRange getter (including IDL) to allow for returning null here. And we do still want to store the actual start/end container so AbstractRange will need to support some kind of "is opaque" switch.

annevk · 2025-12-08T07:14:37Z

dom.bs

+updated using the rules above.</p>
+
+<p>The <dfn export for=PlainTextRange id=dom-plaintext-range-stringifier>stringification
+behavior</dfn> must run these steps:</p>


As I mentioned in whatwg/html#11478 (comment) I don't think exposing toString() is correct at this level.

initial changes

e19d60b

stephanieyzhang changed the title ~~initial changes~~ Add FormControlRange interface Sep 23, 2025

update to match format of other ranges

d7b3bee

dandclark reviewed Sep 26, 2025

View reviewed changes

stephanieyzhang added 2 commits September 29, 2025 11:27

address dan's comments

05b6b0a

formatting

e5b3361

stephanieyzhang added 2 commits September 29, 2025 13:19

pt 2 of Dan's comments

55b34b7

remove commit-sha

9858599

dandclark reviewed Sep 30, 2025

View reviewed changes

fixes for dan's comments

f65c447

This was referenced Oct 9, 2025

[cssom-view-1] Add PlainTextRange geometry APIs (getClientRects/getBoundingClientRects) w3c/csswg-drafts#12904

Draft

Integrate PlainTextRange hooks into text controls (input/textarea) whatwg/html#11741

Draft

FormControlRange Interface whatwg/html#11478

Open

stephanieyzhang added 2 commits October 16, 2025 14:38

add geometry methods

a6c4f52

rename to PlainTextRange + tpac changes

c947ca1

stephanieyzhang changed the title ~~Add FormControlRange interface~~ Add PlainTextRange interface Dec 4, 2025

annevk reviewed Dec 8, 2025

View reviewed changes

stephanieyzhang mentioned this pull request Dec 8, 2025

Rename FormControlRange to OpaqueRange and incorporate TPAC design feedback MicrosoftEdge/MSEdgeExplainers#1204

Open

Add PlainTextRange interface #1404

Are you sure you want to change the base?

Add PlainTextRange interface #1404

Uh oh!

Conversation

stephanieyzhang commented Sep 12, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dandclark left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rniwa commented Sep 29, 2025

Uh oh!

stephanieyzhang commented Sep 30, 2025

Uh oh!

rniwa commented Sep 30, 2025

Uh oh!

dandclark left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dandclark Sep 30, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dandclark commented Sep 30, 2025

Uh oh!

annevk Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

annevk Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

annevk Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

annevk Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

4 participants

stephanieyzhang commented Sep 12, 2025 •

edited by pr-preview bot

Loading